- Supported Image File Formats
- The Megadrive/Genesis Palette
- Tiles and Tile Mappings
- Image Editor Palette Issues and Suggestions
- Tile Optimization
- Loops and Crossing Paths
The Import Feature
-
The "Import from Image" option in the "File" menu will display a set of
options for importing palette colors, any of the 3 Tile sizes, and
sections of Level Layout.
Selecting Data Types for Import
-
Each of the available data types will be listed in on the selection menu,
and will be accompanied by a checkbox. Click to place a check in the checkbox next
to the names of all desired data types.
Note that when selecting "Layout", "Chunks, or "Blocks", the smaller Tile formats are also selected automatically, as any smaller art that does not already exist within the data will need to be added for the other incoming Tiles or Layout to display properly.
Level Layout
-
When importing Level Layout sections, the layout is imported to the "Plane Clipboard",
and must then be manually pasted onto Plane A (Foreground) or Plane B (Background) within
the Level Editor.
Tile Paging
-
Some games further separate Tilesets into "Pages". This method is generally used to
vary art between acts, and even portions of the same level, by storing common graphics
on lower pages, and using higher pages for graphics that need to be swapped out.
When the target game uses Tile Paging, it is necessary to specify which Tile page should receive the incoming Tile data. The "Chunks", "Blocks", and "Tiles" options each have two entries that are used for this purpose:
| Page to Search | - | This setting specifies the ID number of the first Page that should be searched for duplicate Tiles. In many cases, this option would remain "0", but in some instances, it is desireable to skip the checking of lower pages and allow Tiles from those lower pages to be duplicated in an upper page |
| Page to Append | - | This setting specifies the ID number of the Page that the incoming Tile data should be inserted into, if no match was found in any of the Pages starting at "Page to Search" |
When a game does not use Paging, these values should remain set to "0". These values should not be set higher than the highest existing Page ID.
It is important to know how many Pages the level data is using, and what they are being used for. In some cases, the Pages are split between Foreground (Plane A) and Background (Plane B), as opposed to the usual method of sharing Tiles between these Planes.
Palette Importing
-
The Palette importing section contains three additional settings:
| Num Entries | - | This setting specifies the number of palette entries that should be copied from the source image |
| Source ID | - | This setting specifies the ID number of the first source image palette entry to be copied |
| Dest ID | - | This setting specifies the ID number of the first game palette entry into which the incoming color data will be copied |
Selecting the Source Image and Performing the Import
-
Once all of the desired settings have been made, click "Select image and import".
A file selection menu will appear, requesting the
location and name of the graphics file that contains the data to import. Once the
file is selected, the import begins.
The Status Window will announce the beginning and end of the import process, as well as give the number of Tiles that were previously stored in the level, and the number of Tiles that are stored after the import has completed.
Important Setup Notes
-
There are a few things to bear in mind when creating art externally.
Not following these rules will likely cause undesired results:
Supported Image File Formats
-
SonED2 can read 256-color PCX or TGA images of any size, as long as the height and
width are multiples of the largest Tile size being imported:
| Tiles | - | Height/Width must be multiples of 8 |
| Blocks | - | Height/Width must be multiples of 16 |
| Level Layout or Chunks (With 128x128 Chunks) | - | Height/Width must be multiples of 128. |
| Level Layout or Chunks (With 256x256 Chunks) | - | Height/Width must be multiples of 256. |
The Megadrive/Genesis Palette
-
The Megadrive/Genesis uses a 64-color palette. The palette itself is divided
into 4 sub-palettes, or "rows", each of which may only be used one at a time. This is because
each pixel in an 8x8 Tile is stored as a 4-bit value, with a maximum value
of 15. This value is an index into a palette row containing 16 colors (0-15),
with color 0 on each row being "transparent" (it is not drawn).
In the Sonic the Hedgehog games, the first color entry on row 3 controls the "Backdrop Color". This is the color that appears where nothing else is drawn to the screen, including the screen borders displayed by some system versions, and can be taken advantage of to use a full set of 16 colors for the background.
The total number of colors that can be generated by the Megadrive/Genesis is 512, which is less than the total number that can be generated by a PC. This is because color components are also stored as 4-bit values, and only even values are valid (0, 2, 4, 6, 8, 10, 12, 14). Most art programs use an 8-bit value (0-256) for the Red, Green, and Blue components of a color. Both have the same color range, but the Genesis has significantly fewer shades in-between. Its 4-bit component values correspond to multiples of 32 in the 8-bit component values. Anything in-between would be rounded down to the nearest multiple of 32, meaning that shades that are too similar will become the exact same color. For that reason, a chart containing all 512 possible colors is included in the file "MDColor.png" in the "Docs" folder:
Using this chart to select colors will help eliminate bad color value problems.
Tiles and Tile Mappings
-
Levels are built in several steps, beginning with 8x8 Tile graphics.
The Tiles are then formed into 16x16 "Blocks", which contain drawing direction and palette row ID data for each Tile, and the ID of the Solidity Height Map that should be used to set which parts of the block are "solid".
The Blocks are used to build "Chunks", which are either 256x256 or 128x128, depending on the project settings and the target game. These Chunks contain data for each Block that defines drawing direction and the type of reaction a player should have to the Block's assigned Height Map.
Finally, the Chunks are used to build the level layout.
Because the 16x16 Blocks contain a palette row setting for each 8x8 Tile entry, a single Tile may be reused several times with different palette rows to show the same form with different colors. When importing Blocks or Chunks, SonED2 will use the last pixel found within a Tile to determine which palette row to assign to it within the Block. If colors from different rows are used within the Tile, they will become colors from the row assigned to the Tile (Ex: A pixel using palette index 17 in a Tile that has been assigned row 3 will be end up using palette index 33, because both are "index 1" in their respective rows). The very first color in the 64-color palette (entry 0) is safe to use anywhere in any Tile to represent transparency, however.
Image Editor Palette Issues and Suggestions
-
Some art programs do strange things with the palette, such as not allowing
the user to specify which palette index to draw with if two palette entries
contain the exact same color (For example, if entry 4 and entry 17 contain
the exact same color, attempting to draw with entry 17 will actually draw
with entry 4, which can be seen by then changing the color in entry 4).
This can be avoided by changing one of the colors completely, or just
slightly, so that there is no reason for the image program not to use the selected color, and
then changing it back when finished drawing. The same error can occur when
copying art from one image to another, and will occur if a palette is loaded
with a "Match Nearest Color" option.
It is always a good idea to double-check the image to make sure that the graphics program hasn't caused any palette errors. Also, Color Reduction options will re-order the palette, so they should never be used on any primary images, where the palette and art intended for import are being built and stored.
It is best to use an art program that has a resizeable grid. Using the grid will help ensure that all patterns are drawn in sizes that are multiples of 8, and that art that is moved or pasted is positioned properly. If the art doesn't fit properly into the 8x8 grid, extra Tiles will be created, reducing the amount of Tiles that can be added later. Larger shapes that form Blocks and Chunks also need to conform to a grid. Blocks should be positioned on a 16x16 grid, and Chunks should be positioned on a 128x128 or 256x256 grid, depending on the target game's Chunk size. If the Tiles are not positioned properly in the image, they will not be imported properly, because the program cannot otherwise know where the Tile begins and ends.
Tile Optimization
-
SonED2 will attempt to "optimize" Tile usage by automatically detecting
"mirrored" and/or "flipped" Tiles and Blocks. When an 8x8 or 16x16 shape is
encountered that can be displayed by changing the direction of an existing
Tile/Block is found, that Tile is not stored, but instead,
the previously-stored version is used to build the Block or Chunk that is
currently being imported, and the proper drawing direction flags are set.
When importing art that looks the same as art that is already stored, but should contain different property settings, a new entry is not made for the similar Tile, because SonED2 cannot know that different properties are required when it is reading an image file that does not contain them. The Tile must be copied within the editor, and the appropriate properties set manually.
Art that is already stored with properties set, when run through the import function again, will not be stored in new entires with no properties set, but will use the art that was already stored, with the properties that were already set. If more than one entry that looks the same is already stored, the art being imported will be regarded as the first entry that is found, so if it should actually correspond to a later entry, it must be corrected manually within the editor. This could also cause unnecesary "copies" of larger Tile types, so it is recommended that art that has already been imported not be included with any new art intended for import.
Loops and Crossing Paths
-
Games that use a two-path solidity system use Path Swapper objects
to accomplish loops and crossing paths, however, games that only use
a one-path solidity system (Sonic 1 and Sonic CD) use a hard-coded
test against Chunk IDs.
Each level in a game using one-path solidity can be given two Chunk IDs to define as "loops". These Chunks must be followed immediately by a visibly-identical copy, with the original having solidity filled in on the right half, and the copy having solidity filled in on the left half (For example, if Chunks 4 and 8 are "loop" Chunks, they must be made solid on the right side, and must also have copies in Chunks 5 and 9, made solid on the left side). The original and copy are swapped back and forth in-game depending on which side the player is moving toward them from.
When working with the one-path solidity system, the IDs of the "loop" Chunks must correspond with the Chunk IDs that were supplied to the game program. Otherwise, they will not function. This means that "loop" Chunks for a modified level must be given the same IDs as the "loop" Chunks for the original level, or the game must be modified to recognise the new "loop" Chunk IDs.